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Abstract 

We study the properties of input-consuming derivations of moded logic 
programs. Input-consuming derivations can be used to model the behavior 
of logic programs using dynamic scheduling and employing constructs such 
as delay declarations. 

We consider the class of nicely-moded programs and queries. We show 
that for these programs a weak version of the well-known switching lemma 
holds also for input-consuming derivations. Furthermore, we show that, 
under suitable conditions, there exists an algebraic characterization of 
termination of input-consuming derivations. 

1 Introduction 

Most of the recent logic programming languages provide the possibility of em- 
ploying dynamic scheduling, i.e., a runtime mechanism determining which atoms 
in a query are selectable and which ones are not. In fact, dynamic scheduling has 
proven to be useful in a number of applications; among other things, it allows 



one to model coroutining, as shown in [Nai92, HL94 , and parallel executions, 



as shown in [Nai88| 



Let us use the following simple examples to show how dynamic scheduling 
can be enforced by using delay declarations and how it can prevent nontermi- 
nation and unnecessary computations. Consider the program APPEND 

app([ ] ,Ys,Ys) 



appl, L J , is , YSJ . 
app([H|Xs] ,Ys, [H|Zs]) <- app(Xs,Ys,Zs) . 
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together with the query 

Ql := app(Xs, [5,6] ,Ys) , app( [1,2] , [3,4] ,Xs) . 

In this query, if we select and resolve the leftmost atom, we could easily have 
to face one of the following two problems. First, the possibility of nontermi- 
nation: This is the case if we repeatedly resolve the leftmost atom against the 
second clause. The second problem is that of inefficiency. If, for instance, in 
Qi we resolve the leftmost atom against the first clause, we obtain the query 
app([l,2] , [3,4] , [ ]). This will eventually fail, yielding to (unnecessary) 
backtracking. Notice that if one employs the rightmost selection rule, Qi would 
terminate with success and without backtracking. Basically, the problem when 
selecting app(Xs, [5,6] ,Ys), is that we do not know which clause we should 
use for resolving it, and the only practical way for getting to know this is by 
waiting until the outermost functor of Xs is known: If it is the empty list [ ] 
we know that we should use the first clause, if it is the list-constructor symbol 
we know that we should use the second clause, if it is something else again, we 
know then that the query fails. Notice that the same problems arise for the 
query 

Q 2 := app([l,2] , [3,4] ,Xs), app(Xs, [5,6] ,Ys) . 

if the rightmost selection rule is considered. 

This shows the usefulness of a mechanism for preventing the selection of 
those atoms which are not sufficiently instantiated. Such a mechanism is in fact 



offered by most modern languages: In GHC [Ucd8S] programs are augmented 



with guards in order to control the selection of atoms dynamically. Moded 



Flat GHC [UM94 uses an extra condition on the input positions, which is 
extremely similar to the concept of input-consuming derivation step we refer to 
the sequel: The resolution of an atom with a definition must not instantiate the 



input arguments of the resolved atom. On the other hand, G odel JHL94 1 and 



ECLiPSe |WNS97| use delay declarations, and SICStus Prolog ]SIC97[ employs 



block declarations (which are a special kind of delay declarations). Both delay 
and block declarations check the partial instantiation of some arguments of 
calls. For instance, the standard delay declaration for APPEND is 

di := delay app(Ls, _, _) until nonvar(Ls) . 

This declaration forbids the selection of an atom of the form app(s,i,u) unless 
s is a non-variable term, which is precisely what we need in order to run the 
queries Qi or Q 2 efficiently. 

The adoption of dynamic scheduling has the disadvantage that various pro- 
gram properties that have been proven for logic and pure Prolog programs do 
not apply any longer. 

The goal of our research is the study of termination properties. This is mo- 
tivated by the fact that most of the literature on termination of logic programs 



(see De Schreye and Decorte [DD94| for a survey on this subject) assumes the 
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standard Prolog selection rule, i.e., the leftmost one. Notable exceptions are 



Bezem |Bez93 and Cavedon [Cav89 who provide results for all selection rules. 
There are only few authors who tackled the specific problem of verifying the 
termination of logic programs with dynamic scheduling. Namely, Apt and Luit- 
jes [AL95], Marchiori and Teusink [ MT95| and Smaus [3ma99b|. We compare 
our results with the ones in [A.L95, MT95, 3ma99b] in the concluding section. 

Another feature of logic programs which does not hold in presence of dy- 
namic scheduling is the well-known switching lemma, which is, for instance, at 
the base of the result on the independence of the selection rule. In this paper we 
show that - under certain conditions - a weak form of the well-known switching 
lemma holds. 



In order to recuperate at least part of the declarative reading of l ogic pro- 
gramming, we follow here the same approach to dynamic scheduling as |Sma99b| 
and we substitute the use of delay declarations by the restriction to input- 
consuming derivations. The definition of input-consuming derivation is done 
in two phases. First we give the program a mode, that is, we partition the 
positions of each atom into input and output positions. Then, in presence of 
modes, input- consuming derivation steps are precisely those in which the input 
arguments of the selected atom will not be instantiated by the unification with 
the clause's head. If in a query no atom is resolvable via an input-consuming 
derivation step and a failure does not arise then we have a deadlock situation^. 

For example, the standard mode for the program APPEND reported above, 
when used for concatenating two lists, is app(In,In,Out). Notice that in this 
case the delay declaration d\ serves precisely the purpose of guaranteeing that if 
an atom of the form app(s, t, X) (with X being a variable) is selectable and unifi- 
able with a clause head, then the resulting derivation step is input-consuming. 

It is also worth remarking that, as a large body of literature shows, the 
vast majority of "usual" programs are actually moded and are, in a well-defined 
sense consistent wrt. to their modes (e .g., well-moded, nicely-moded, simply- 
moded, etc.); see for example |AP94b| , |AM94j , or more simply, the tables of 
programs we report in Section [7], or consider for instance the logic programming 
language Mercury |SHC9(| , which requires that its programs are moded (and 
well-moded). 



Contributions of this paper 

In this paper we study some properties of input-consuming derivations. 

In the first place we show that, if we restrict ourselves to programs and 
queries which are nicely-moded, then a weak form of the well-known switching 
lemma holds. 

Furthermore, we study the termination properties of input-consuming deriva- 
tions. For this we define the class of input terminating programs which characteri- 
zes programs whose input-consuming derivations starting in a nicely-moded 



As we discuss in Section 3.2, this notion of deadlock differs, in some way, from the usual 



one, which is given in the case of programs employing delay declarations. 
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query are finite. In order to prove that a program is input terminating, we use 
the concept of quasi recurrent program (similar to, but noticeably less restric- 
tive than the concept of semi-recurrent program introduced in [AP94a ). We 
show that if P is nicely-moded and quasi recurrent then all its input-consuming 
derivations starting from a nicely-moded query terminate. 

Furthermore, we demonstrate that under mild additional constraints (namely, 
simply-modedness and input-recurrency) the above condition is both sufficient 
and necessary for ensuring that all input-consuming derivations starting from a 
nicely-moded query terminate. 

This approach generalizes the method described in |5ma991: ] in two ways: 
First because we also provide conditions which are both necessary and sufficient, 
and secondly because we do not require programs and queries to be well-moded; 
we only assume that they are nicely-moded. This is actually crucial: When 
programs and queries are well-moded, derivations cannot deadlock. Thus, as 
opposed to |Sma99b |, our results capture also termination by deadlock. For 
instance, we can easily prove that the query app(X, Y, Z) terminates. A more 
detailed comparison is presented in the concluding section. 

We also show that the results presented in this paper can be extended to 
programs and queries which are permutation nicely- or simply- moded, |SHK98|. 

To evaluate the practicality of the results we present, we consider the pro- 
grams from various well-known collections, and we check whether they satisfy 
the conditions of our main theorem. 

The paper is organized as follows. Section ^contains some preliminary nota- 
tions and definitions. In Section || input-consuming derivations are introduced 
and some properties of them are proven. In Section |1| we prove that, for nicely- 
moded input-consuming programs, a left switching lemma holds. In Section 
^| a method for proving input termination of programs is presented, first in a 
non-modular way, then for modular programs. In Section ^ we show that this 
method is necessary for the class of simply-moded and input-recursive programs. 
Section discusses the applicability of our results through simple examples of 
programs and reports the results obtained by applying our method to various 
benchmarks. Finally, Section || concludes the paper. 



2 Preliminaries 



The reader is assumed to be familiar with the terminology and the basic results 
of logic programs ]Apt90|, |Apt97|, [Llo87[. 



2.1 Terms and Substitutions 

Let T be the set of terms built on a finite set of data constructors C and a 
denumerable set of variable symbols V. A substitution 9 is a mapping from V 
to T such that Dom(9) — {X\ 9{X) ^ X} is finite. For any syntactic object 
o, we denote by Var{o) the set of variables occurring in o. A syntactic object 
is linear if every variable occurs in it at most once. We denote by e the empty 
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substitution. The composition 9a of the substitutions 9 and a is defined as the 
functional composition, i.e., 9a(X) = a(9(X)). We consider the pre-ordering < 
(more general than) on substitutions such that 9 < a iff there exists 7 such that 
9 j = a. The result of the application of a substitution 9 to a term t is said an 
instance of t and it is denoted by tO. We also consider the pre-ordering < (more 
general than) on terms such that t < t' iff there exists 9 such that tO — t' . We 
denote by s=s the associated equivalence relation [variance). A substitution 9 is 
a unifier of terms t and i' iff <0 = t'9. We denote by mgu(t, t') any mosi general 
unifier (mgu, in short) of £ and t' . An mgu of terms t and £' is called relevant 
iff Var{9) C Var(i) U Var(i')- 



2.2 Programs and Derivations 

Let P be a finite set of predicate symbols. An atom is an object of the form 
p{t\, . . . , t n ) where p £ P is an n-ary predicate symbol and t\, . . . , t n £ T . Given 
an atom A, we denote by Rel(A) the predicate symbol of A. A query is a finite, 
possibly empty, sequence of atoms Ai, . . . , A m . The empty query is denoted 



by □. Following the convention adopted in [Apt97], we use bold characters to 
denote queries. A clause is a formula H <— B where is an atom (the head) 
and B is a query (the body). When B is empty, H *— B is written H <— and is 
called a imii clause. A program is a finite set of clauses. We denote atoms by 
A, B, H, . . . , queries by Q, A, B, C, . . . , clauses by c, d, . . . , and programs by P. 

Computations are constructed as sequences of "basic" steps. Consider a 
non-empty query A, B, C and a clause c. Let H <— B be a variant of c variable 
disjoint from A, B, C. Let B and H unify with mgu 9. The query (A, B, C)9 
is called a resolvent of A, £?, C awe? c im'f/i selected atom B and mgu 9. A 
derivation step is denoted by 

A,5,C^p, c (A,B,C)0 

The clause H «— B is called its input clause. The atom i? is called the selected 
atom of A, J3, C. 

If P is clear from the context or c is irrelevant then we drop the reference 
to them. A derivation is obtained by iterating derivation steps. A maximal 
sequence 

5 := Qo ==^p> lC1 Qi ==>p,c 2 • ' ' Qn =>p,c„ + i Qn+i ' ' ' 

is called a derivation of P U {Qo} provided that for every step the standardiza- 
tion apart condition holds, i.e., the input clause employed is variable disjoint 
from the initial query Q and from the substitutions and the input clauses used 
at earlier steps. 

Derivations can be finite or infinite. If 8 := Qq =>p, Cl • • • ==>p. Cn Qn is a 

finite prefix of a derivation, also denoted 5 := Qo 1 — » Q n with 9 = 9\ ■ ■ ■ 8 n , 
we say that 5 is a partial derivation and 9 is a partial computed answer substi- 
tution of P U {Qo}- If <5 is maximal and ends with the empty query then 9 is 
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called computed answer substitution (c.a.s., for short). The length of a (partial) 
derivation S, denoted by len(S), is the number of derivation steps in 6. 
The following definition of B-step is due to Smaus 



Definition 1 (B-step) Let A, B, C => (A, B, C)8 be a derivation step. We 
say that each atom in B0 is a direct descendant of B, and for each atom E 
in (A, C), E9 is a direct descendant of E. We say that E is a descendant of 
F if the pair (E, F) is in the reflexive, transitive closure of the relation is a 

direct descendant of. Consider a derivation Qq ==h- ■ ■ ■ ==>• Qf ■ ■ ==> Qj ===> 

Qj+i ■ ■ ■■ We say that Qj ==> Qj+\ ■ ■ ■ is a B-step if H is a subquery of Qi and 
the selected atom in Qj is a descendant of an atom in B . 

3 Modes and Input-Consuming Derivations 

In this section we introduce the concept of input-consuming derivation which is 
strictly related to the notion of mode; we discuss the relations between input- 
consuming derivations and programs using delay declarations; we recall the 
notion of nicely-moded program and state some properties. 

3.1 Input-Consuming Derivations 

Let us first recall the notion of mode. A mode is a function that labels as input 
or output the positions of each predicate in order to indicate how the arguments 
of a predicate should be used. 

Definition 2 (Mode) Consider an n-ary predicate symbol p. A mode for p is 
a function m p from {1, . . . , n} to {In, Out}. 

If m p (i) = In (resp. Out), we say that i is an input (resp. output) position of p 
(wrt. m p ). We assume that each predicate symbol has a unique mode associated 
to it; multiple modes may be obtained by simply renaming the predicates. 

If Q is a query we denote by In(Q) (resp. Out(Q j) the sequence of terms 
filling in the input (resp. output) positions of predicates in Q. Moreover, when 
writing an atom as p(s, t), we are indicating with s the sequence of terms filling 
in the input positions of p and with t the sequence of terms filling in the output 
positions of p. 

The notion of input-consuming derivation was introduced in 
is defined as follows. 

Definition 3 (Input-Consuming) 

• An atom p(s,t) is called input-consuming resolvable wrt. a clause c := 
p(u, v) <— Q and a substitution Q iff Q — mgu(p(s, t),p(u, v)) and s = s9. 



5ma99b| and 
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• A derivation step 

A,B,C=U C (A,B,C)0 

is called input-consuming iff the selected atom B is input- consuming re- 
solvable wrt. the input clause c and the substitution 9. 

• A derivation is called input-consuming iff all its derivation steps are input- 
consuming. 

The following lemma states that we are allowed to restrict our attention to 
input-consuming derivations with relevant mgu's. 

Lemma 4 Let p(s, t) and p(u, v) be two atoms. If there exists an mgu 9 of 
pis, t) and p(u, v) such that s9 = s, then there exists a relevant mgu $ o/p(s,t) 
and p(u, v) such that si9 = s. 

Proof. Since p(s, t) and p(u, v) are unifiable, there exists a relevant mgu 9 re i of 



them (cfr. [ Apt97|, Theorem 2.16). Now, 9 re i is a renaming of 9. Thus s9 re i is a 
variant of s. Then there exists a renaming p such that Dom(p) C Var(s, t, u, v) 
and s9 re ip = s. Now, take d — 9 re ip. □ 

From now on, we assume that all mgu's used in the input-consuming deriva- 
tion steps are relevant. 

Example 5 Consider the program REVERSE with accumulator in the modes de- 
fined below. 

mode reverse(In, Out), 
mode reverse_acc(In,Dut,In) 

reverse (Xs ,Ys) <— reverse_acc (Xs , Ys , [ ]). 
reverse_acc ( [ ],Ys,Ys). 

reverse_acc ( [X I Xs] , Ys , Zs) <— reverse_acc (Xs , Ys , [X I Zs] ) . 

The derivation d o/REVERSE U {reverse([Xl, X2], Zs)} depicted below is input- 
consuming. 

S := reverse([Xl, X2], Zs) => reverse_acc([Xl, X2], Zs, []) => 

reverse_acc([X2], Zs, [XI]) => reverse_acc([ ], Zs, [X2, XI]) □ . 

3.2 Input-Consuming vs. Delay Declarations 

Delay declarations are by far the most popular mechanism for implementing 
dynamic scheduling. However, being a non-logical mechanism, they are difficult 



to model and there are few proposals concerning their semantics [Mar97| and 
[ |FGMP97| . 



An alternative approach to dynamic scheduling, which is much more declar- 



ative in nature, has been proposed by Smaus [3ma99t]. It consists in the use 
of input-consuming derivations. 
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There is a main difference between the concept of delay declaration and 
the one of input-consuming derivation: While in the first case only the atom 
selectability is controlled, in the second one both the atom and the clause se- 
lectability are affected. In fact, in presence of delay declarations, if an atom is 
selectable then it can be resolved with respect to any program clause (provided 
it unifies with its head); on the contrary, in an input-consuming derivation, if 
an atom is selectable then it is input-consuming resolvable wrt. some, but not 
necessarily all, program clauses, i.e, only a restricted class of clauses can be used 
for resolution. 

Also the concept of deadlock has to be understood in two different ways. For 
programs using delay declarations a deadlock situation occurs when no atom in 
a query satisfies the delay declarations (i.e., no atom is selectable), while for 
input-consuming derivations a deadlock occurs when no atom in a query is 
resolvable via an input-consuming derivation step and the derivation does not 
fail, i.e., there is some atom in the query which unifies with a clause head but 
the unification is not input-consuming. 

In spite of these differences, in many situations there is a strict relation be- 
tween programs using delay declarations and input-consuming derivations. This 



relation is studied by Smaus in his PhD thesis [ Sma99a | . More precisely, Smaus 
proves a result that relates block declarations and input-consuming derivations. 
A block declaration is a special case of delay declaration and it is used to de- 
clare that certain arguments of an atom must be non-variable when the atom 



is selected for resolution. In Chapter 7 of [3ma99a|, Smaus shows that block 
declarations can be used to ensure that derivations are input-consuming. In 
force of this result and of practical experience, we might claim that in most 
"usual" moded programs using them, delay declarations are employed precisely 
for ensuring the input-consumedness of the derivations. 

In fact, delay declarations are generally employed to guarantee that the 
interpreter will not use an "inappropriate" clause for resolving an atom (the 
other, perhaps less prominent, use of delay declarations is to ensure absence of 
runtime errors, but we do not address this issue in this paper). This is achieved 
by preventing the selection of an atom until a certain degree of instantiation 
is reached. This degree of instantiation ensures then that the atom is unifiablc 
only with the heads of the "appropriate" clauses. In presence of modes, we 
can reasonably assume that this degree of instantiation is the one of the input 
positions, which are the ones carrying the information. Now, it is easy to see 
that a derivation step involving a clause c is input-consuming iff no further 
instantiation of the input positions of the resolved atom could prevent it from 
being resolvable with c. Therefore c must belong to the set of "appropriate" 
clauses for resolving it. Thus, the concepts of input-consuming derivation and 
of delay declarations are often employed for ensuring the same properties. 

3.3 Nicely-Moded Programs 

In the sequel of the paper we will restrict ourselves to programs and queries 
which are nicely-moded. In this section we report the definition of this concept 
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together with some basic important properties of nicely- moded programs. 

Definition 6 (Nicely-Moded) 

• A query Q := pi(s%, ti), . . . ,p n (s„, t„) is nicely-moded i/tj.,. . .,t n is a 
linear sequence of terms and for all i G {1, . . . , n} 



Var(s l ) n |J Var(tj 



• A clause c — p(so,to) <— Q is nicely-moded if Q is nicely-moded and 

n 

Var{s ) n |J Var{tj) = 0. 

In particular, every unit clause is nicely-moded. 

• A program P is nicely-moded if all of its clauses are nicely-moded. 

Note that a one-atom query p(s, t) is nicely-moded if and only if t is linear 
and Var(s) n Var(t) = 0. 

Example 7 

• The program APPEND in the modes app (In , In , Out) is nicely-moded. 

• The program REVERSE with accumulator in the modes depicted in Exam- 
ple [3| is nicely-moded. 

• The following program MERGE is nicely-moded. 

mode merge ( In , In , Out ) . 

merge (Xs, [ ] ,Xs) . 
merge ( [ ] ,Xs,Xs) . 

merge ( [X I Xs] , [Y I Ys] , [Y I Zs] ) <- Y < X , merge ( [X I Xs] , Ys , Zs) . 

merge ( [X I Xs] , [Y I Ys] , [X I Zs] ) <- Y > X , merge (Xs , [Y I Ys] , Zs) . 

merge([X|Xs] , [X|Ys] , [X|Zs]) <- merge (Xs, [X|Ys] ,Zs) . 



The following result is due to Smaus [3ma99a|, and states that the class of 
programs and queries we are considering is persistent under resolution. 

Lemma 8 Every resolvent of a nicely-moded query Q and a nicely-moded clause 
c, where the derivation step is input- consuming and Var{Q) n Var(c) = 0, is 
nicely-moded. 



The following Remark, also in [ 5ma99a , is an immediate consequence of the 
definition of input-consuming derivation step and the fact that the mgu's we 
consider are relevant. 

Remark 9 Let the program P and the query Q := A,p(s, t), C be nicely-moded. 

7/A,p(s,t),C =^=> (A,B, C)0 is an input- consuming derivation step with se- 
lected atom p(s, t), then A8 = A. 
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4 The Left Switching Lemma 



The switching lemma (see for instance [Apt97], Lemma 3.32) is a well-known 
result which allows one to prove the independence of the computed answer 
substitutions from the selection rule. 

In the case of logic programs using dynamic scheduling, the switching lemma 
does not hold any longer. For example, in program APPEND reported in the 
introduction (together with the delay declaration d\) we have that the rightmost 
atom of Q2 is selectable only after the leftmost one has been resolved; i.e., the 
switching lemma cannot be applied. 

Nevertheless we can show that, for input-consuming derivations of nicely- 
moded programs, a weak version of the switching lemma still holds. Intuitively, 
we show that we can switch the selection of two atoms whenever this results in 
a left to right selection. For this reason, we call it left switching lemma. 

First, we need one technical result, stating that the only variables of a query 
that can be "affected" in an input-consuming derivation process are those occur- 
ring in some output positions. Intuitively, this means that if the input arguments 
of a call are not "sufficiently instantiated" then it is delayed until it allows for an 
input-consuming derivation step (if it is not the case then a deadlock situation 
will arise). 

Lemma 10 Let the program P and the query Q be nicely-moded. Let 5 :— 

Q | — -> Q 1 be a partial input- consuming derivation of PU{Q}. Then, for all 
x G Var(Q) and x g' Var(Out(Q)), x8 = x. 

Proof. Let us first establish the following claim. 

Claim 11 Let z and w be two variable disjoint sequences of terms such that 
w is linear and 9 — mgu(z,w). If s\ and S2 are two variable disjoint terms 
occurring in z then s±9 and S2O are variable disjoint terms. 



Proof. The result follows from Lemmata 11.4 and 11.5 in [ AP94a[ . □ 



We proceed with the proof of the lemma by induction on len(S). 
Base Case. Let len(S) = 0. In this case Q = Q' and the result follows 
trivially. 

Induction step. Let len(d) > 0. Suppose that Q := A,p(s,t),C and 

S := A,p(s, t), C Jk- (A, B, C)^ ^ Q' 

where p(s, t) is the selected atom of Q, c := p(u, v) <— B is the input clause 
used in the first derivation step, 9\ is a relevant mgu of p(s, t) and p(u, v) and 
9 = 9\92- 

Letxe Var(A,p(s, t), C) and x Var(Out(A,p(s,t), C)). We first show that 

x8 l = x (1) 

We distinguish two cases. 
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(a) x £ Var(s). In this case, property ([!]) follows from the hypothesis that 
S is input-consuming. 

(b) x $ Var(s). Since x 6 Var(A,p(s, t), C), by standardization apart, we 
have that x $ Var(p(u, v)). Moreover, since x £" Var(Out(A, p(s, t), C)), it also 
holds that x ^ Var(p{s, t)). Then, property follows from relevance of 0i. 

Now we show that 

x6» 2 = x (2) 

Again, we distinguish two cases: 

(c) £ Var((A, B, C)#i). In this case, because of the standardization apart 

condition, x will never occur in (A,B,C)0i ^ Q'. Hence, a: £ Dom{9 2 ) and 
x#2 = 

(d) x € Var((A, B, C)#i). In this case, in order to prove (Q) we show 
that x £ Var(Out((A,'B,C)di)). The result then follows by the inductive 
hypothesis. 

From the standardization apart, relevance of 9\ and the fact that the first 
derivation step is input-consuming, it follows that Dom(6\) fl Var(Q) C Var(t). 

From the hypothesis that Q is nicely-moded, Var(t) n Var(Out(A, C)) = 0. 
Hence, Var(Out(A, C))6»i = Var(0«*(A, C)). Since x £ Var(0irf(A, C)), this 
proves that x ^ Var(Out((A, C)9i)). 

It remains to be proven that x £" Var(Out(B9i). We distinguish two cases. 

(dl) x g Var(s). Since x ^ Var(p(s,t)), the fact that x g Var(Out(B6i) 
follows immediately by standardization apart condition and relevance of 9±. 



(d2) x £ Var(s). By known results (see [ Apt97 ], Corollary 2.25), there exists 
two relevant mgu <j\ and a 2 such that 

• 6»l = (71(72, 

• (7i = mgu(s, u), 

• (72 = mgu(t(7l, V(7l). 

From relevance of (7! and the fact that, by nicely-modedness of Q, Var(s) n 
Var(t) = 0, we have that tu\ = t, and by the standardization apart condition 
Var(t)n Var(vCTi) = 0. Now by nicely-modedness of c, Var(u)n Var(0wi(B)) = 
0. Since o\ is relevant and by the standardization apart condition it follows that 

Var(ucri) n Var(Ou*(Boi)) = (3) 

The proof proceeds now by contradiction. Suppose that x £ Var(0ut(Bcr±a2))- 
Since by hypothesis x £ Var(s), and s = u<Jia 2 , we have that Var(u<Tia 2 ) n 
Var(OMi(B(7 1 <7 2 )) ^ 0. By (§, this means that there exist two distinct variables 
Z\ and z 2 in Var(a 2 ) such that € Var(Out(3ai)), z 2 £ Var(uai) and 

Var( Zl a 2 ) D Var(z 2 a 2 ) ^ (4) 

Since, by the standardization apart condition and relevance of the mgu's, Var(a 2 ) 
C Var(vcri) U Var(t) and ( Var(0«t(B(7i)) U Var(uffi)) n Var(t) = 0, we have 
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that z\ and z-i are two disjoint subterms of \G\. Since 02 = mgu(t,vai), t is 
linear and disjoint from va\, (Q) contradicts Claim O. □ 

The following corollary is an immediate consequence of the above lemma 
and the definition of nicely-moded program. 

Corollary 12 Let the program P and the one- atom query A be nicely-moded. 
Let 5 := A 1 — : > Q' be a partial input- consuming derivation of P U {A}. Then, 
for all x £ Var(In(A)), x9 = x. 

Next is the main result of this section, showing that for input-consuming 
nicely-moded programs one half of the well-known switching lemma holds. 

Lemma 13 (Left-Switching) Let the program P and the query Qq be nicely- 
moded. Let S be a partial input- consuming derivation of P U {Qo} of the form 

5 := Qo =^ci Q\ ' " ' Qn =^c„ + i Qn+1 =^c, 1 + 2 Qn+2 

where 

• Q n is a query of the form A, B, C, D, E, 

• Qn+i is a resolvent of Q n and c n+ \ wrt. D, 

• Qn+2 is a resolvent of Q n +i and c n +2 wrt. B6 n+ \. 

Then, there exist Q' n+ i, 0' n +i, 0' n+2 and a derivation 8' such that 

&n+\&n+2 = O'n + lO'n+2 

and 

5' '■= Qq =>c t Ql ■ ■ ■ Qn ==>c„ +2 Qn+1 =>c, l + 1 Qn+2 

where 5' is input- consuming and 

• 6 and 5' coincide up to the resolvent Q n , 

• Q'n+i is a resolvent of Q n and c n+ 2 wrt. B, 

• Qn+2 is a resolvent of Q' n+1 and c n +i wrt. D0' n+1 , 

• 8 and 5' coincide after the resolvent Q n +2- 

Proof. Let B := p(s,t), D := q(u, v), c n +i ■= q(u',v') <— D and c n +2 '■= 
p(s',t') <— B. Hence, 9 n +i = Tngu(q(u, v), q(u' , v')) and 

u#„ + i = u, since S is input-consuming. (5) 

By (^) and the fact that Q n is nicely-moded and # rl +i is relevant, we have that 
p(s,t)6» n+ i =p(s,t). Then, 6> Il+2 = mgu(p(s, t)6 n+1 ,p(s\ t')) = mgu(p(s, t),p(s', t')) 
and 

s^„ + 2 = s, since S is input-consuming. (6) 
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Moreover |^ 

n+1 9 n+2 = mgu{p(s,t) =p(s',t'),g(u,v) = g(u',v')} = n+2 0' n+2 (7) 

where 

e 'n+2 = mgu(q(u,v)6 n+2 ,q(u' ,v')9 n+2 ) = mgu(q(u, v)6 n+2 , q(u' , v')). 
We construct the derivation 5' as follows. 



5 '■ — Qo ^*ci Ql ' ' ' Qn ^c„ + 2 Qn+l ^c„ + i Qn+2 



where 



(8) 



By (^), Qn =^c„ +2 Q n +i is an input-consuming derivation step. Observe now 
that 

= u0 n+2 n+2 , (by(|) 
= u6>„ + i6>„ +2 , (by (7)) 
= ufl„ +2 , (by (5)) 

= n9' n+1 , (by (I). 

This proves that Q n+1 => c „ + i Qn+2 i s an input-consuming derivation step. □ 



This result shows that it is always possible to proceed left-to-right to resolve 
the selected atoms. Notice that this is different than saying that the leftmost 
atom of a query is always resolvable: It can very well be the case that the 
leftmost atom is suspended and the one next to it is resolvable. However, if the 
leftmost atom of a query is not resolvable then we can state that the derivation 
will not succeed, i.e., either it ends by deadlock, or by failure or it is infinite. 

It is important to notice that if we drop the niccly-modedness condition the 
above lemma would not hold any longer. For instance, it does not apply to the 
query Qi of the introduction which is not nicely-moded. In fact, the leftmost 
atom of Qi is resolvable only after the rightmost one has been resolved at least 
once. 

The following immediate corollary will be used in the sequel. 

Corollary 14 Let the program P and the query Q := A,B be nicely-moded. 
Suppose that 

6 := A, B ^ Ci,C 2 

that is a partial input- consuming derivation of P U {Q} where Ci and C 2 are 
obtained by partially resolving A and B, respectively. Then there exists a partial 
input- consuming derivation 

5' :=A,B^ Ci, B0i A- Ci, C 2 

where all the A-steps are performed in the prefix A,B C^B^ and 6 = 
Q\Q 2 . 

2 We use the notation mgu(E) to denote the mgu of a set of equations E, see |Apt97], 
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5 Termination 



In this section we study the termination of input-consuming derivations. To 



this end we refine the ideas of Bezem [Bez93| and Cavedon |Cav89| who studied 



the termination of logic programs in a very strong sense, namely with respect to 



all selection rules, and of Smaus [3ma99b| who characterized terminating input 



consuming derivations of programs which are both well and nicely-moded. 

5.1 Input Terminating Programs 

We first introduce the key notion of this section. 

Definition 15 (Input Termination) A program is called input terminating 
iff all its input- consuming derivations started in a nicely-moded query are finite. 

The method we use in order to prove that a program is input terminating 
is based on the following concept of modcd level mapping due to Etalle et al. 



[EBC99| 



Definition 16 (Moded Level Mapping) Let P be a program and Bp be the 
extended Herbrand base^ for the language associated with P. A function \ \ is a 
moded level mapping for P iff: 

• it is a function \ \ : Bp — > N from atoms to natural numbers; 

• for any t and u ; |p(s, t) | = |p(s, u) | . 
For A £ Bp, \A\ is the level of A. 

The condition |p(s,t)| = \p(s, u)| states that the level of an atom is inde- 
pendent from the terms in its output positions. There is actually a small yet 



: In [EBC99| 



EBC9S] only 



important difference between this definition and the one in [EBC99 
the level mapping is defined on ground atoms only. Indeed, in 
well- moded atoms are considered, i.e., atoms with ground terms in the input 
positions. Here, instead, we are considering nicely-moded atoms whose input 
positions can be filled in by (possibly) non-ground terms. 

Example 17 Let us denote by TSize(t) the term size of a term t, that is the 
number of function and constant symbols that occur in t. 

• A moded level mapping for the program APPEND reported in the introduction 
is as follows: 

I app (x s ,y s ,z s ) I = TSize (x s ) . 



3 The extended Herbrand base of P is the set of equivalence classes of all (possibly non- 
ground) atoms, modulo renaming, whose predicate symbol appears in P. As usual, an atom 
is identified with its equivalence class. 
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• A moded level mapping for the program REVERSE with accumulator of Ex- 
ample |^ is the following: 

I reverse (x s , y s ) I = TSize(x s ) 

I reverse_acc (x s ,y s ,z s ) I = TSize(x s ) ■ 

5.2 Quasi Recurrency 

In order to give a sufficient condition for termination, we are going to employ 
a generalization of the concept of recurrent and of semi-recurrent program. The 
first notion (which in the case of normal programs, i.e., programs with negation, 



coincides with the one of acyclic program) was introduced in [Bez93, AB91| 



and independently in [Cav91| in order to prove universal termination for all 



selection rules together with other properties of logic programs. Later, Apt 



and Pedreschi [AP94a] provided the new definition of semi- recurrent program, 
which is equivalent to the one of recurrent program, but it is easier to verify in 
an automatic fashion. In order to proceed, we need a preliminary definition. 

Definition 18 Let P be a program, p and q be relations. We say that p refers 
to q in P iff there is a clause in P with p in the head and q in the body. We 
say that p depends on q and write p □ q in P iff (p, q) is in the reflexive and 
transitive closure of the relation refers to. 

According to the above definition, pc^q = p\ZqAp^iq means that p and 
q are mutually recursive, and pZlq=p^iqApc£q means that p calls q as a 
subprogram. Notice that □ is a well-founded ordering. 

Finally, we can provide the key concept we are going to use in order to prove 
input termination. 

Definition 19 (Quasi Recurrency) Let P be a program and | \:Bp —> N be 
a moded level mapping. 

• A clause of P is called quasi recurrent with respect to | if for every 
instance of it, H *— A, B, C 

if Rel(H) ~ Rel(B) then \H\ > \B\. (9) 

• A program P is called quasi recurrent with respect to | | if all its clauses 
are. P is called quasi recurrent if it is quasi recurrent wrt. some moded 
level mapping | | : Bp — > N. 

The notion of quasi recurrent program differs from the concepts of recurrent 
and of semi-recurrent program in two ways. First, we require that \H\ > \B\ 
only for those body atoms which mutually depend on Rel(H); in contrast, both 
the concept of recurrent and of semi- recurrent program require that \H\ > \B\ 
(\H\ > \B\ in the case of semi-recurrency) also for the atoms for which Rel(H) ^ 
Rel(B). Secondly, every instance of a program clause is considered, not only 
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ground instances as in the case of (semi-) recurrent programs. This allows us 
to treat directly any nicely-moded query without introducing the concept of 
houndedness |AP94a| or cover as in ]MT95[ . 

It is worthwhile noticing that this concept almost coincides with the one 
of ICD- acceptable program introduced and used in [3ma99b|. We decided to 



use a different name because we believe that referring to the word acceptable 
might lead to confusion : The concept of acceptable program was introduced 
by Apt and Pedreschi [ AP93 , AP94a] in order to prove termination of logic 
programs using the left-to-right selection rule. The crucial difference between 
recurrency and acceptability lies in the fact that the latter relies on a model M; 
this allows condition (|J) to be checked only for those body atoms which are in 
a way "reachable" wrt. M. Hence, every recurren t progr am is acceptable but 
not vice- versa. As an aside, Marchiori and Teusink [MT95] introduce the notion 
of delay recurrent program although their concept is based on the presence of 
a model M. Our definition does not rely on a model, and so it is much more 
related to the notion of recurrent than the one of acceptable program. 

We can now state our first basic result on termination, in the case of non- 
modular programs. 

Theorem 20 Let P be a nicely-moded program. If P is quasi recurrent then P 
is input terminating. 

Proof. It will be obtained from the proof of Theorem ^4] by setting R = 0. □ 

Example 21 Consider the program MERGE defined in Example Let \ \ be the 
moded level mapping for MERGE defined by 

Imerge (x s , y s , z s ) I = TSize{x s ) + TSize(y s ) . 

It is easy to prove that MERGE is quasi recurrent wrt. the moded level mapping 
above. By Theorem [#^ ; all input- consuming derivations of MERGE started with 
a query merge(s, t, u), where u is linear and variable disjoint from s and t, are 
terminating. 



5.3 Modular Termination 

This section contains a generalization of Theorem ^ to the modular case, as 
well as the complete proofs for it. The following lemma is a crucial one. 

Lemma 22 Let the program P and the query Q := A±, . . . , A n be nicely-moded. 
Suppose that there exists an infinite input- consuming derivation 5 of P U {Q}. 
Then, there exist an index i£ {1, . . . ,n} and substitution 9 such that 

1. there exists an input- consuming derivation 5' of P U {Q} of the form 
6' := A lt . . . , A n ^ C, (A u ..., A n )6 



2. there exists an infinite input- consuming derivation of P U {A;#}. 



1G 



Proof. Let S := A\,. . . ,A n i — > • • • be an infinite input-consuming derivation 
of PU{Q}. Then 5 contains an infinite number of v4fc-steps for some k € 
{1, . . . , n}. Let i be the minimum of such k. Hence S contains a finite number 
of A, -steps for j e {1, . . . , i — 1} and there exists C and D such that 

6:=A 1 ,...,A n mC,D M - 

where Ai, . . . , A n i — > C, D is a finite prefix of S which comprises all the Aj- 
steps of S for j e {1, . . . , i — 1} and C is the subquery of C, D consisting of the 
atoms resulting from some A,-step (j 6 {1, . . . , i — 1}). By Corollary [14|, there 
exists an infinite input-consuming derivation 5' such that 

6' :=A 1 ,...,A n ^C,(A t ,...,A n )6^C,r>^--- 

where $ = 98' . This proves (i). 

Now, let 6" := C, {A,, A n )9 ^C,D — > ■ ■ ■. Note that in 5" the atoms 
of C will never be selected and, by Remark 0, will never be instantiated. Let 
6"' be obtained from 8" by omitting the prefix C in each query. Hence 5"' is 
an infinite input-consuming derivation of P U {(Ai, . . . , A n )8} where an infinite 
number of A^-steps are performed. Again, By Remark ^, for every finite prefix 
of 5"' of the form 

Mo, (A i+1 , . . . , A n )e Ad^d,^ d;, t>' 2 

where Di and D2 are obtained by partially resolving AiO and (A+i, • • ■ , A n )9, 
respectively, and Di, D2 => D' l5 D 2 is an A j -step for some j S {i + 1, . . . , n}, 
we have that D' x = Di. Hence, from the hypothesis that there is an infinite 
number of A^-steps in 8" ', it follows that there exists an infinite input-consuming 
derivation of P U {Ai8}. This proves (ii). □ 

The importance of the above lemma is shown by the following corollary of 
it, which will allow us to concentrate on queries containing only one atom. 

Corollary 23 Let P be a nicely-moded program. P is input terminating iff for 
each nicely-moded one-atom query A all input- consuming derivations of P U {A} 
are finite. 

We can now state the main result of this section. Here and in what follows we 
say that a relation p is defined in the program P if p occurs in a head of a clause 
of P, and that P extends the program R if no relation defined in P occurs in R. 

Theorem 24 Let P and R be two programs such that P extends R. Suppose 
that 

• R is input terminating, 

• P is nicely-moded and quasi recurrent wrt. a moded level mapping \ \ : 
Bp — > N. 



17 



Then P U R is input terminating. 

Proof. First, for each predicate symbol p, we define dep P {p) to be the number 
of predicate symbols it depends on. More formally, dep P (p) is defined as the 
cardinality of the set {q\ q is defined in P and p □ q). Clearly, dep P (p) is 
always finite. Further, it is immediate to see that if p ~ q then dep P (p) = 
dep P (q) and that if p □ q then dep P (p) > dep P (q). 

We can now prove our theorem. By Corollary ^3], it is sufficient to prove 
that for any nicely-moded one-atom query A, all input-consuming derivations 
of P U {A} arc finite. 

First notice that if A is defined in R then the result follows immediately 
from the hypothesis that R is input terminating and that P is an extension of 
R. So we can assume that A is defined in P. 

For the purpose of deriving a contradiction, assume that 5 is an infinite 
input-consuming derivation of (P U R) U {A} such that A is defined in P. Then 

S:=AJ^(B 1 ,...,B n )9 1 J^--- 

where H <— B\ , . . . , B n is the input clause used in the first derivation step 
and B\ = mgu{A 1 H). Clearly, (Pi, . . . ,B n )9\ has an infinite input-consuming 
derivation in PUR. By Lemma ^2], for some i G {l,...,n} and for some 
substitution 02, 

1. there exists an infinite input-consuming derivation of (P U R) U {A} of the 
form 

v4 (Pi, . . . , B n )9i i C, (P^ . . . , B n )6x02 • • • ; 

2. there exists an infinite input-consuming derivation of P U {Pi#i#2}- 

Notice also that BflxQi is nicely-moded. Let now 9 = Q\Qi- Note that HO <— 
(Pi, . . . , Pn)^ is an instance of a clause of P. 

We show that (2) cannot hold. This is done by induction on (dep P (Rel(A)), \ A\) 
wrt. the ordering >- defined by: (m,n) y (m',n') iff either m > m' or m = ml 
and n > n' . 

Base. Let dep P {Rel(A)) — (\A\ is arbitrary). In this case, A does not 
depend on any predicate symbol of P, thus all the Bi as well as all the atoms 
occurring in its descendents in any input-consuming derivation are defined in 
R. The hypothesis that R is input terminating contradicts (2) above. 

Induction step. We distinguish two cases: 

1. Rel(H) □ Rel(Bi), 

2. Rel(H) ~ Rel(B t ). 

In case (a) we have that dep P {Rel(A)) = dep P {Rel{H9)) > dep P {Rel{BiO)). 
So, (depp(Pd(A)),|A|) = (de Pp (Rel(H9)),\H8\) y (depp(Rel(Bi9)),\Bi9\). 
In case (&), from the hypothesis that P is quasi recurrent wrt. | |, it follows that 
\H9\ > \BiO\. 
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Consider now the partial input-consuming derivation A i — > C, (B i7 . . . , B n )9. 
By Corollary [jj] and the fact that | | is a moded level mapping, it follows that 
\A\ = \A6\ = \H9\. Therefore, (dep P (Rel(A)),\A\) = (dep P (Rel(H0)),\H6\) y 
(dep P (Rel(BiO)), \Bi9\). In both cases, the contradiction follows by the induc- 
tive hypothesis. □ 

Example 25 The program FLATTEN using difference-lists is nicely-moded with 
respect to the modes described below, provided that one replaces '\ " by ", ", as 
we have done here. 

mode f latten(In, Out) . 
mode flatten_dl(In,Dut,In) . 
mode constant (In) . 
mode ^ (In, In) . 

flatten (Xs.Ys) <— f latten_dl(Xs ,Ys , [ ]). 
flatten_dl( [ ] ,Ys,Ys) . 

flatten_dl(X, [XlXs] ,Xs) <- constant (X) , X / [ ]. 
flatten_dl( [XlXs] ,Ys,Zs) <- f latten_dl(Xs ,Yls ,Zs) , 

flatten_dl(X,Ys,Yls) . 

Consider the moded level mapping for FLATTEN defined by 

I f latten(a; s , y s ) I = TSize(x s ) 

I f latten_dl(:r s , y s , z s ) I = TSize(x s ) . 

It is easy to see that the program FLATTEN is quasi recurrent wrt. the moded level 
mapping above. Hence, all input- consuming derivations of program FLATTEN 
started with a query flatten(s,t), where t is linear and variable disjoint from 
s, are terminating. 



6 Termination: A Necessary Condition 

Theorem ^o] provides a sufficient condition for termination. The condition is 
not necessary, as demonstrated by the following simple example. 

mode p(In,Dut) . 

p(X,a) <-p(X,b). 
p(X,b) . 

This program is clearly input terminating, however it is not quasi recurrent. If 
it was, we would have that |p(X, a)| > |p(X,b)|, for some moded level mapping 
| (otherwise the first clause would not be quasi recurrent). On the other hand, 
since p(X, a) and p(X, b) differ only for the terms filling in their output positions, 
by definition of moded level mapping, p(X, a) = |p(X,b)|. Hence, we have a 
contradiction. 
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Nevertheless, as shown by other works, e.g., [Bez93, AP93, EBC99 , it is 
important to be able to give a characterization of termination, i.e., a condition 
which is necessary and sufficient to ensure termination. To this purpose is 
dedicated this section. 

6.1 Simply-Moded Programs 

As demonstrated by the example above, in order to provide a necessary condi- 
tion for termination we need to further restrict the class of programs we consider. 
The first problem is that we should rule out those situations in which termina- 
tion is guaranteed by the instantiation of the output positions of some selected 
atom, as it happens in the above example. For this we restrict to simply-moded 
programs which are nicely-moded programs with the additional condition that 
the output arguments of clause bodies are variables. 

Definition 26 (Simply-Moded) 

• A query Q (resp., a clause c = H <— Q) is simply-moded if it is nicely- 
moded and Out(Q) is a linear sequence of variables. 

• A program P is simply-moded iff all of its clauses are simply-moded. 

It is important to notice that most programs are simply-moded (see the 



mini-survey at the end of |AP93|) and that often non simply-moded programs 



can naturally be transformed into simply-moded ones. 
Example 27 



The programs REVERSE of Example [|. MERGE of Example || and FLATTEN 

of Example l2q are all simply-moded. 



• Consider the program LAST which extends REVERSE; 

mode last (In, Out) . 

last (Ls , E) <— reverse (Ls , [E I J ) . 

This program is not simply-moded since the argument filling in the output 
position in the body of the first clause is not a variable. However, it can 
be transformed into a simply-moded one as follows: 

mode last (In, Out) . 

mode selectf irst (In, Out) . 

last (Ls ,E) <— reverse (Ls ,Rs) , selectf irst (Rs ,E) . 
selectf irst( [E I J ,E) . 

The following lemma, which is an immediate consequence of Lemma 30 in 



[AL95], shows the persistence of the notion of simply-modedness. 



Lemma 28 Every resolvent of a simply-moded query Q and a simply-moded 
clause c, where the derivation step is input- consuming and Var(Q)C\ Var(c) = 0, 
is simply-moded. 
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6.2 Input-Recursive Programs 



Unfortunately, the restriction to simply-moded programs alone is not sufficient 
to extend Theorem ^ by a necessary condition. Consider for instance the 
following program QUICKSORT: 

mode qs(In,0ut). 

mode part (In, In, Out , Out) . 

mode app ( In , In , Out ) . 

qs([ ] , [ ]). 

Ci:= qs( [X|Xs] ,Ys) ^ part(X,Xs, Littles, Bigs) , 
qs(Littles,Ls) , 
qs(Bigs,Bs) , 
app(Ls, [XlBs] ,Ys) . 

part(X, [],[],[]). 

part(X, [YlXs] , [YlLs] ,Bs) ^X>Y, part (X,Xs ,Ls ,Bs) . 
part(X, [YlXs] ,Ls, [YlBs] ) ^X<=Y, part(X,Xs,Ls,Bs) . 

This program is simply-moded and input terminating^. However it is not 
quasi recurrent. Indeed, there exist no moded level mapping | | such that, for ev- 
ery variable-instance, |qs([X|Xs], Ys)| > |qs(Littles, Ls)| and |qs([X|Xs], Ys)| > 
|qs(Bigs, Bs)|. This is due to the fact that, in clause ci there is no direct link 
between the input arguments of the recursive calls and those of the clause head. 
This motivates the following definition of input-recursive programs. 

Definition 29 (Input-Recursive) Let P be a program. 

• A clause H <— A, B,C of P is called input-recursive if 

if Rel(H) ~ Rel(B) then Var{In{B)) C Var{In(H)). 

• A program P is called input-recursive if all its clauses are. 

Thus, we say that a clause is input-recursive if the set of variables occurring 
in the arguments filling in the input positions of each recursive call in the clause 
body is a subset of the set of variables occurring in the arguments filling in 
the input positions of the clause head. Input-recursive programs have strong 
similarities with primitive recursive functions. 

Example 30 

• The programs APPEND of the introduction, REVERSE of Example and 
MERGE of Example [?| are all input-recursive. 

4 Provided that one models the built-in predicates > and <= as being defined by (an infinite 
number of) ground facts of the form >(m,n) and <=(m,n). The problem here is that the 
definition of input-consuming derivation does not consider the presence of built-ins. 
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• The program FLATTEN of Example is not input-recursive. This is due 
to the presence of the fresh variable Yls in a body atom of the last clause. 

• QUICKSORT, is not input-recursive. In particular, clause c\ is not input- 
recursive. 



6.3 Characterizing Input Terminating Programs 

We can now prove that by restricting ourselves to input-recursive and simply- 
moded programs, the condition of Theorem ^ is also a necessary one. 

To prove this, we follow the approach of Apt and Pedreschi when character- 



izing terminating programs [AP94a . First we introduce the notion of IC-tree 



that corresponds to the notion of S-tree in [ AP94a | and provides us with a rep- 
resentation for all input-consuming derivations of a program P with a query Q, 
then we define a level mapping which associates to every atom A the number 
of nodes of a given IC-tree and finally we prove that P is quasi recurrent wrt. 
such a level mapping. 

Definition 31 (IC-tree) An IC-tree for P U {Q} is a tree whose nodes are 
labelled with queries such that 

• its branches are input- consuming derivations of P U {Q}, 

• every node Q has exactly one descendant for every atom A of Q and every 
clause c from P such that A is input- consuming resolvable wrt. c. This 
descendant is a resolvent of Q and c wrt. A. 

In this tree, a node's children consist of all its resolvents, "modulo renaming", 
via an input-consuming derivation step wrt. all the possible choices of a program 
clause and a selected atom. 

Lemma 32 (IC-tree 1) An IC-tree for P\J{Q} is finite iff all input- consuming 
derivations of P U {Q} are finite. 

Proof. By definition, the IC-trees are finitely branching. The claim now follows 
by Konig's Lemma. □ 

Notice that if an IC-tree for PU{Q} is finite then all the IC-trees for PU{Q} 
are finite. 

For a program P and a query Q, we denote by nodes l p(Q) the number of 
nodes in an IC-tree for P U {Q}. The following properties of IC-trees will be 
needed. 

Lemma 33 (IC-tree 2) Let P be a program, Q be a query and T be a finite 
IC-tree for PU{Q}. Then 

(i) for all non-root nodes Q' in T, nodes l p(Q') < nodes l p(Q), 

(ii) for all atoms A of Q, nodesp(A) < nodesp(Q). 
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Proof. Immediate by Definition [U] of IC-tree. □ 

We can now prove the desired result. 

Theorem 34 Let P be a simply-moded and input-recursive program. If P is 
input terminating then P is quasi recurrent. 

Proof. We show that there exists a moded level mapping | | for P such that P 
is quasi recurrent wrt. | |. 

Given an atom A, we denote with A* an atom obtained from A by replacing 
the terms filling in its output positions with fresh distinct variables. Clearly, 
we have that A* is simply-moded. Then we define the following moded level 
mapping for P: 

\A\ = nodes^(A*). 

Notice that, the level \A\ of an atom A is independent from the terms filling in 
its output positions, i.e., | | is a moded level mapping. Moreover, since P is input 
terminating and A* is simply-moded (in particular, it is nicely-moded) , all the 
input-consuming derivations of P U {^4*} are finite. Therefore, by Lemma [52], 
nodes p(A*) is defined (and finite), and thus \A\ is defined (and finite) for every 
atom A. 

We now prove that P is quasi recurrent wrt. | |. 

Let c : H <— A, B, C be a clause of P and H9 <— A9, B9, CO be an instance of 
c (for some substitution 9). We show that if Rel(H) ~ Rel(B) then \H6\ > \B8\. 

Let H = p(s,t). Hence, (H6)* — p(s9,x.) where x is a sequence of fresh 
distinct variables. Consider a variant d : H' <— A', B', C of c variable disjoint 
from (H9)*. Let p be a renaming such that d = cp. Clearly, (HO)* and H' 
unify. Let p, — mgu((H9)* , H') — mgu(( H9)* , H p) — mgu(p(s9,x.),p(s,t)p). 



By properties of substitutions (see Apt97|), since x consists of fresh variables, 



there exists two relevant mgu o~\ and 02 such that 

• <Ti = mgu(s9,sp), 

• o~2 — mgu(x.o~i,tpai). 

Since sp < s9, we can assume that Dom(a\) C Var(sp). Because of standardi- 
zation apart, since x consists of fresh variables, xrri = x and thus o~2 = 
mgu(~x.,tpo-i). Since x is a sequence of variables, we can also assume that 
Dom(a 2 ) C Var(x). Therefore Dom(p) C Var(Out((H9)*)) U Var(In(Hp)). 
Moreover, since (A', B' , C')p, — (A, B, C)pp,, we have that 

(H6y^(A,B,C) Pf i 

is an input-consuming derivation step, i.e., (A, B, C)p/i is a descendant of (H9)* 
in an IC-tree for P U {(H9)*}. 

By definition of /i, s9 = sp/i; hence 

{pv)\in(H) = 0|s- (!0) 
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Let now B — p(u, v). By ( |10[ ) and the hypothesis that c is input-recursive, 
that is Var(In(B)) C Var(In(H)) = Var(s), it follows that 

up/i = u(p^)| Jn(H ) = u6»| s = u6. (11) 

Moreover, since c' is simply-moded, In(H p)D Out(B p) — 0. Hence, by definition 
of /i and standardization apart, Dom(p) n Out(Bp) = 0, i.e., 

V/3/1 = vp. (12) 

Therefore, by @) and (|l|), Bp^ = p(u, w)ppi = p(u0, vp) = (B8)* , i.e., 

Bpp = {BO)*. (13) 

Hence, 

\H0\ = nodes p{(H6)*) by definition of | | 



> nodesp ((A, B, C)pfi) by Lemma 33 

> nodes p(Bpp) by Lemma 33 



(i) 
(ii) 



nodes^({B9)*) by (|1J) 

£>6>| by definition of 



□ 



7 Applicability 

This section is intended to show through some examples the applicability of our 
results. Then, programs from various well-known collections are analyzed. 

7.1 Examples 

It is worth noticing that, since the definition of input-consuming derivation 
is independent from the textual order of the atoms in the clause bodies, the 
results we have provided (Theorems |o[ [24| and ^) hold also in the case that 



programs and queries are permutation nicely- (or simply-) moded [SHK98|, that 
is programs and queries which would be nicely- (or simply-) moded after a 
permutation of the atoms in the bodies. Therefore, for instance, we can apply 
Theorems p0| and p4|to the program FLATTEN as it is presented in [ Apt97| (except 
for the replacement of "\" with ","), i.e., 

flatten (Xs.Ys) <— f latten_dl(Xs ,Ys , [ ]). 
flatten_dl( [ ] ,Ys,Ys) . 

flatten_dl(X, [XlXs] ,Xs) <- constant (X) , X ^ [ ]. 
flatten_dl( [XlXs] ,Ys,Zs) <- f latten_dl(X,Ys ,Yls) , 

flatten_dl(Xs,Yls,Zs) . 

where the atoms in the body of the last clause are permuted with respect to the 
version of Example Ea. 
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Let us consider again the program APPEND of the introduction with its natural 
delay declaration: 

mode app(In,In,Out) 
app([ ] ,Ys,Ys) . 

app([H|Xs] ,Ys, [H|Zs]) <- app(Xs,Ys,Zs) . 

delay app(Xs,_,_) until nonvar(Xs) . 

Let Q be the set of one-atom queries of the form app (s,t,Z) where s and 
t are any terms and Z is a variable disjoint from s and t. Observe that Q 
is closed under resolution: Each resolvent in a derivation starting in a query 
from Q is still a query from Q. Moreover, because of the presence of the delay 
declaration, only atoms whose first argument is a non- variable term are allowed 
to be selected. Thus, selectable atoms have the form app(s,i,Z) where 

(1) s is a non-variable term, 

(2) t is any term and Z is a variable disjoint from s and t. 

Any derivation of APPEND starting in a query of Q is similar to an input- 
consuming one. This follows from the fact that for any selectable atom A 
and clause's head H, there exists a mgu 9 which does not affect the input 
arguments of A. In fact, let A be a selectable atom of Q. If A unifies with 
the head of the first clause then, by (1), s is the empty list [ ] and 9 — 
mgu(A, H) = {Ys/t, Z/t}. Otherwise, If A unifies with the head of the second 
clause then, by (1), s is a term of the form [S1IS2] and 9 — mgu(A,H) = 
{H/si, Xs/s2, Ys/t, Z/[si|Zs]}. By (2) it follows that, in both cases, s9 = s and 
t9 = t, i.e., 9 does not affect the input arguments of A. 

Moreover, it is easy to check that APPEND is quasi recurrent wrt. the moded 
level mapping depicted in Example |l7|. Since it is nicely-moded, by applying 
Theorem ^o|it follows that it is input terminating. By the arguments above, we 
can conclude that all the derivations of APPEND in presence of the delay decla- 
ration d\ and starting in a (permutation) nicely-moded query are finite. Hence, 
in particular, we can state that all the derivations of APPEND starting in the 
query Q\ of the introduction, which is not nicely-moded but it is permutation 
nicely-moded, are finite. 



7.2 Benchmarks 

In order to assess the applicability of our results, we have looked into four 
collections of logic programs, and we have checked those programs against the 
three classes of programs: (permutation) nicely-moded, input terminating and 
quasi recurrent programs. The results are reported in Tables 1 to 4. These 
tables clearly show that our results apply to the large majority of the programs 
considered. 

In Table 1 the programs from Apt's collection are considered, see [Apt97|. 
The programs from the DPPD's collection, maintained by Leuschel and available 



25 



at the URL: http://dsse.ecs.soton.ac.uk/~mal/systems/dppd.htm], are referred 
to in Table 2. Table 3 considers various programs from Lindenstrauss's collection 
(see the URL: tittp:/ /www.cs.huji.ac.il/~naomi]). Finally, in Table 4 one finds 
the (almost complete) list of programs by F. Bueno, M. Garcia de la Banda and 
M. Hermenegildo that can be found at the URL: http:/ /www. clip. dia.fi.upm.es. 

For each program we specify the name and the modes of the main proce- 
dure. Then we report whether or not the program is (permutation) nicely- 
moded (NM), input terminating (IT), and quasi recurrent (QR). Notice that 
for programs which are not input terminating, because of Theorem ^o], it does 
not make sense to check whether or not they are quasi recurrent. For this rea- 
son, we leave blank the cells in the column QR corresponding to non-input 
terminating programs. 

Finally, Table 5 reports the list of programs from previous tables which have 
been found to be input terminating but not quasi recurrent. For these programs, 
the notion of quasi recurrency does not provide an exact characterization of 
input termination. In particular, Theorem |34| does not apply. In order to 
understand which of the hypothesis of the theorem does not hold, we report 
in Table 5 whether or not these programs are simply-moded (SM) and input- 
recursive (IR). 



8 Conclusion and Related Works 

In this paper we studied the properties of input-consuming derivations of nicely- 
moded programs. 

This study is motivated by the widespread use of programs using dynamic 
scheduling controlled by delay declarations. In fact, as we have motivated in 



Section 3.2, we believe that in most practical programs employing delay decla- 
rations these constructs are used for guaranteeing that the derivation steps are 
input-consuming . 

In the first place, we showed that for nicely-moded programs a weak version 
of the well-known switching lemma holds: If, given a query (A, B, C, D, E), 
D is selected before B in an input-consuming derivation, then the two resolu- 
tion steps can be interchanged while maintaining that the derivation is input- 
consuming. 

Secondly, we presented a method for proving termination of programs and 
queries which are (permutation) nicely-moded. We also showed a result charac- 
terizing a class of input terminating programs. 

In the literature, the paper most related to the present one is certainly 
[ 5ma99bt . Our results strictly generalize those in [Sma99t] in the fact that we 



drop the condition that programs and queries have to be well-moded. This is 
particularly important in the formulation of the queries. For instance, in the 
program FLATTEN of Example our results show that every input-consuming 
derivation starting in a query of the form f latten(£, s) terminates provided that 



t is linear and disjoint from s, while the results of |Sma99b| apply only if t is 



a ground term. Note that well-moded queries (in well-moded programs) never 
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terminate by deadlock, since the leftmost atom of each resolvent is ground in 
its input positions and hence selectable. This does not hold for nicely-moded 
queries which might deadlock. Our method allows us thus to cope also with this 
more difficult situation: For instance we can prove that all derivations of APPEND 
starting in app(X,Y, Z) are terminating. In practice the result of [3ma99b] iden- 
tify a class of programs and queries which is both terminating and deadlock free. 
While deadlock is clearly an undesirable situation, there are various reasons why 
one might want to prove termination independently from the absence of dead- 
lock: In the first place, one might want to prove absence of deadlock using a 
different tool than by employing well-moded programs. Secondly, in some situa- 
tions absence of deadlock might be difficult or impossible to prove, like in a mod- 
ular context in which the code of some module is not known, hence not analyz- 
able: consider for instance the query generator_l (Xls) , generator_2(X2s) , 
append(Xls ,X2s ,Zs) ., where the generators are defined in different modules; 
our results allow us to demonstrate that if the generators terminate, then the 
above query terminates. On the other hand, one cannot determine whether it 
is deadlock free unless one has a more precise specification of the generators. 
Thirdly, it is well-known that one of the goals of dynamic scheduling is pre- 
cisely enforcing termination; in this respect a deadlock can be regarded as the 
situation in which "all else failed" . Our system allows us to check how effective 
dynamic scheduling is in enforcing termination. 

Concluding our comparison with [3ma99b], for the class of (permutation) 
simply- moded and input-recursive programs, we provide an exact characteriza- 
tion of input termination. A similar result is not present in |Sma99b|. 

Apt and Luitjes [AL95| have also tackled the problem of the termination of 
programs in presence of dynamic scheduling. The techniques employed in it are 
based on determinacy checks and the presence of successful derivations, thus 
are completely different from ours. It is nevertheless worth mentioning that 
[AL95] reports a special ad-hoc theorem, in order to prove that, if u is linear 
and disjoint from s then the query app(s,i, u) terminates. This is reported in 
order to show the difficulties one encounters in proving termination in presence 
of dynamic scheduling. Now, under the further (mild) additional condition that 
u be disjoint from t, the termination of app(s,<,u) is a direct consequence of 
our main result. 

Another related paper is the one by Marchiori and Teusink [ MT9£ ] . However, 
Marchiori and Teusink make a strong restriction on the selection rule, which has 
to be local; this restriction actually forbids any form of coroutining. Moreover, 
[MT95| allows only safe delay declarations; we do not report here the definition 
of safe delay declaration, we just say that it is rather restrictive: For instance, 
the delay declaration we have used for APPEND is not safe (a safe one would 
be delay app(X,_,_) until list (X) ). Actually, their requirements go beyond 
ensuring that derivations are input-consuming. 

Applicability and effectiveness of our results have been demonstrated by 
matching our main definitions against the programs of four public program 
lists. These benchmarks showed that most of the considered programs are nicely- 
moded (for a suitable mode) and quasi recurrent (wrt. a suitable level mapping). 
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Table 1: Programs from Apt's Collection 





MM 


TT 
1 J. 






T\ri\/r 

IN 1V1 


TT 
1 J_ 




app(ln,_,_) 


yes 


yes 


yes 


ordered(In) 


yes 


yes 


yes 


app(_,_,In) 


yes 


yes 


yes 


overlap (_, In) 


yes 


yes 


yes 


app^uut,in,tjut j 


yes 


no 




overlap (In, Out) 


yes 


no 




append3(In,In,In,0ut) 


yes 


yes 


yes 


pcrm(_,In) 


yes 


yes 


yes 


color _map (In, Out) 


yes 


no 




pcrm(In,Out) 


yes 


no 




color _map (Out, In) 


yes 


no 




qsort(In,_) 


yes 


yes 


no 


color _map (In, In) 


yes 


yes 


yes 


qsort(Out,In) 


yes 


no 




QCboive^in,_j 


yes 


no 




icvei se^in,^ 


yes 


yes 


yes 


even(In) 


yes 


yes 


yes 


reversc(Out,In) 


yes 


no 




fold(In,In,Out) 


yes 


yes 


yes 


sclcct(_,In,_) 


yes 


yes 


yes 


list (In) 


yes 


yes 


yes 


sclcct(_,_,In) 


yes 


yes 


yes 


ltc(In,_) 


yes 


yes 


yes 


select (In, Out, Out) 


yes 


no 




lte(_,In) 


yes 


yes 


yes 


subsct(In,In) 


yes 


yes 


yes 


map(In,_) 


yes 


yes 


yes 


subset (In, Out) 


yes 


no 




map(_,In) 


yes 


yes 


yes 


subset (Out, In) 


yes 


no 




member(_,In) 


yes 


yes 


yes 


sum(_,In,_) 


yes 


yes 


yes 


mcmbcr(In,Out) 


yes 


no 




sum(_,_,In) 


yes 


yes 


yes 


mcrgcsort(In,_) 


yes 


yes 


no 


sum(In,Out,Out) 


yes 


no 




mcrgcsort(Out,In) 


yes 


no 




typc(In,In,Out) 


no 


yes 


no 


mcrgcsort_variant(_,_,In) 


yes 


yes 


yes 


type(In,Out,Out) 


no 


no 





Table 2: Programs from DPPD's Collection 





NM 


IT 


QR 




NM 


IT 


QR 


applast(In,In,Out) 


yes 


yes 


yes 


match_app(In,Out) 


yes 


no 




applast(Out,_,_) 


yes 


no 




maxJcnth(In,Out,Out) 


yes 


yes 


yes 


applast(_,Out,_) 


yes 


no 




mcmo_solvc(In,Out) 


yes 


yes 


no 


contains (_,In) 


yes 


yes 


yes 


power (In, In, In, Out) 


yes 


yes 


yes 


contains(In,Out) 


yes 


no 




prune (In, _) 


yes 


yes 


yes 


depth(In,In) 


yes 


yes 


yes 


prune(_,In) 


yes 


yes 


yes 


depth(In,Out) 


yes 


yes 


no 


relative (In,_) 


yes 


no 




depth(Out,In) 


yes 


no 




rclativc(_,In) 


yes 


no 




duplicatc(In,Out) 


yes 


yes 


yes 


rev_acc(In,In,Out) 


yes 


yes 


yes 


duplicatc(Out,In) 


yes 


yes 


yes 


rotate(In,_) 


yes 


yes 


yes 


flipflip(In,Out) 


yes 


yes 


yes 


rotatc(_,In) 


yes 


yes 


yes 


flipflip(Out,In) 


yes 


yes 


yes 


solve(_,_,_) 


yes 


no 




gencratc(In,In,Out) 


yes 


no 




ssupply(In,In,Out) 


yes 


yes 


yes 


liftsolvc(In,Out) 


yes 


no 




tracc(In,In,Out) 


yes 


yes 


yes 


liftsolvc(Out,In) 


yes 


no 




transpose(_,In) 


yes 


yes 


yes 


liftsolvc(In,In) 


yes 


yes 


yes 


transpose(In,Out) 


yes 


no 




match_app(_,In) 


yes 


yes 


yes 


unify(In,In,Out) 


yes 


no 
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Table 3: Programs from Lindcnstrauss's Collection 





i\Ji\/r 

IN 1V1 


TT 


I \ 




i\ii\/r 

1M 1V1 


TT 


I I 


ack(In,In,_) 


ves 


ves 


no 


least(In,_) 


ves 


ves 


ves 


concatenate(In,_,_) 


yes 


yes 


yes 


least(_,In) 


yes 


yes 


yes 


concatenate(_,_,In) 


yes 


yes 


yes 


normaLform (In , _) 


yes 


no 




concatenate(_,In,_) 


yes 


no 




normaLform ( _, In) 


yes 


no 




descendant (In, _) 


yes 


no 




queens(_,Out) 


yes 


yes 


no 


descendant (_,In) 


yes 


no 




quccns(_,In) 


yes 


yes 


yes 


deep(In,_) 


yes 


yes 


yes 


poss(In) 


yes 


yes 


yes 


deep(Out,_) 


yes 


no 




poss(Out) 


yes 


no 




credit (In, _) 


yes 


yes 


yes 


rcwritc(In,_) 


yes 


yes 


yes 


credit (_,In) 


yes 


yes 


yes 


rcwrite(_,In) 


yes 


yes 


yes 


holds(_,Out) 


yes 


no 




transform(_,_,_,Out) 


yes 


no 




holds(_,In) 


yes 


yes 


yes 


transform(_,_,_, In) 


yes 


yes 


yes 


huff man (In, _) 


yes 


yes 


no 


twoleast(In,_) 


yes 


yes 


yes 


huffman(_,In) 


yes 


no 




twoleast(_,In) 


yes 


yes 


yes 



Table 4: Programs from Hcrmencgildo's Collection 







NM 


IT 


QR 


aiakl.pl 


init_vars(In,In,Out,Out) 


yes 


yes 


yes 


ann.pl 


analyze_all (In , Out ) 


yes 


yes 


yes 


bid.pl 


bid(In,0ut,0ut,0ut) 


yes 


yes 


yes 


boyer.pl 


tautology(In) 


yes 


no 




browse.pl 


investigate(In,Out) 


yes 


yes 


yes 


fib.pl 


fib(In,Out) 


yes 


no 




fib_add.pl 


fib(In,Out) 


yes 


yes 


yes 


hanoiapp.pl 


shanoi(In,In,In,In,Out) 


yes 


no 




hanoiapp_suc . pi 


shanoi(In,In,In,In,Out) 


yes 


yes 


yes 


mmatrix.pl 


mmult iply(In,In,Out) 


yes 


yes 


yes 


occur.pl 


occurall(In,In,Out) 


yes 


yes 


yes 


pecphole.pl 


pecphole_opt (In , Out ) 


yes 


yes 


yes 


progcom.pl 


pds(In,Out) 


yes 


yes 


yes 


rdtok.pl 


read_tokcns(In,Out) 


yes 


no 




read.pl 


parse(In,Out) 


yes 


no 




scrializc.pl 


serializc(In,Out) 


yes 


yes 


no 


tak.pl 


tak(In,In,In,Out) 


yes 


no 




tictactoe.pl 


play(In) 


yes 


no 




warplan.pl 


plans (In, In) 


yes 


no 
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Table 5: Input tcrminatining but non-quasi recurrent Programs 





SM 


IR 


mergesort(In,_) 


yes 


no 


qsort(In,_) 


yes 


no 


type(In,In,Out) 


no 


no 


depth(In,Out) 


yes 


no 


mcmo_solvc(In,Out) 


no 


no 


ack(In,In,_) 


yes 


no 


huffman(In,_) 


no 


no 


queens(_,Out) 


no 


no 


scrialize(In,Out) 


no 


no 
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